With luck, this short guide to using SnoopDOS should help you isolate most instances of problems that occur when running programs that don't tell you why they're quitting on you.

1. Firstly, SnoopDOS is available from Aminet in util/moni/snoopdos30.lha.
2. Configure SnoopDOS as shown in the screen shot below. This is done by clicking on the "Functions..." button. Bear in mind that this will generate output for everything and so there is a danger that you'll end up with rather a long report.
   
3. Prepare to run the program, but don't actually do it yet. In other words, open the directory containing the program, open a shell or do whatever is necessary.
4. Now Zap SnoopDOS's buffer (press Right Amiga and Z) so that any display that is presently in the window disappears (to avoid confusion).
5. Run your program. You may notice that it'll run a little slower than normal, but this is just a side effect of running the program in the way shown.
   
6. Click the "Disable" button in SnoopDOS to avoid the possibility of more text being generated to confuse the issue. You should aim to click this button as soon after the program fails as possible, just in case another program starts generating output that might make the task more complicated (as the Amiga may be running any number of programs at once). Now look from the bottom of the list upwards at the far right column labelled "Res." (ie. "Result"), until you find the word "Fail". It is likely that you'll find many instances of this in the whole list. The trick is to pick out the one that causes the problem. This isn't easy! Generally speaking, if a program fails because it can't find a font or a library, it'll look in a number of locations to find it. Take a look at the screen shot below, and you'll notice that the program "SuperProg" is looking for "elusive.library".
   

   It looks in both the current directory and also in "LIBS:" (where the .library files usually reside). In this case, the first fail you've seen is the right one as you know that "elusive.library" isn't anywhere in your system. However, if you know that this library is located somewhere on your hard drive (if you are unsure at this stage, it might be an idea to delve into the Aminet, or get Directory Opus so that you can search for this library on your hard drive). If you find it, you can make an assign. This is simply a matter of making a note of the name of the directory where the search program found the library and doing the following:
   
   

   Assign LIBS: MyDir Add
   where MyDir is the name of the directory where you found the library. There is of course the possibility that the entry you've found is not causing the problem. This is because, as mentioned previously, some programs look in many places to find what they're looking for. So if a program looks in "LIBS:", "L:", "S:", or "DEVS:" (or whatever else) first and can't find the file, it will look somewhere else. If the program then finds what it is looking for, you'll notice "OK" in the far right column. You can check for this by looking in the "Target Name" column for similar names ie. "elusive.library" and "LIBS:elusive.library".
7. A similar problem is that of not being able to find a library of a certain version. In the case of the search for "elusive.library", we look for version zero (ie. any version). Whereas if you look near the top of the list, "xfdmaster.library" version 36 is being requested (and succeeds). Now, if you had version 32 of this library, the program would fail to open the library.
8. There are other things to be wary of when hunting down the problem. Some programs may attempt to check for the existence of a file by trying to "Open" or "Lock" it (see the "Action" column to see which). "CRSnap" (the screen grabber) is a good example of this. A "Fail" in this context doesn't necessarily mean a fault, it merely means that a given file doesn't exist. A program such as this one uses the results of such an action to decide if it should save the screen under a given name, or whether it should pick another one because there is already a file which exists with the same name in that place. Actions labelled "GetVar" again are not necessarily fatal. "GetVar" merely reads "environment variables" (they reside in "ENVARC:", and usually "ENV:") which are basically little text files which contain useful information for a program. Most programs consider them optional, and so a "Fail" here will just mean that a program will rely upon it's built-in settings for certain things. However, not all programs may behave this way, so be careful. Actions that are most commonly the cause of problems are "Open", "Lock", "OpenDev", "OpenLib", and "OpenFont".
9. The name of the program causing all the problems is also something that should be identified as soon as possible (look in the "Process Name" column). This is not necessarily as easy as it sounds. Usually a program will run under the same name as that of the icon you clicked upon or whatever you typed into the Shell. However, in both cases the given program may create "child" programs which will have different names. If you're lucky, these child processes will have a similar name eg. "dopus_function" or something. There is also the possibility that the names might not be so intuitive. When this happens, it is often useful to check the contents of the corresponding entry in the "Target Name" column. This usually gives a clue as to who the program belongs to. In the case of a process called "detached function", you may see a "GetVar" action looking at "dopus/ShowUseDataTypesFirst". This process is therefore part of Directory Opus, as programs rarely play with files belonging to other programs (unless set up to do so either by default or by the user).
10. If the output listing is too large, you may select "Only show fails" from the "Functions..." setup (which can occasionally be less helpful, as you may need to know what has happened prior to a "Fail"). Good hunting!